円安相場だからこそやりたい！AWSコスト最適化のための5ステップ

最近、為替の値動きが気になる方も多いのではないでしょうか？2022年3月に入ってから円安傾向に歯止めがかからず2022年4月13日には、2002年5月以来、実に20年ぶりに1ドル126円をつけました。

126円いっちまったな

【??ドル円 #USD／JPY】126.0770 pic.twitter.com/VIH73oD3fQ

— Atsushi Marumo (@marumo1981) April 13, 2022

昨年、2021年1月時点では1ドル102円だったことを考えると、1年とちょっとでおよそ20%も為替が変動しています。国内ユーザーの多くはAWS利用費を最終的に日本円で支払っていると思いますので、1年前と同じ利用量でUSドルの請求額が同じだとしても、コストは20%増加していることになります。

「クラウドは為替の影響受けるから怖いね、、」

ではなく、クラウドだからこそ柔軟にコストの調整が出来るはずです。

今回は円安によるコスト増加を乗り切るために、コスト最適化のポイントをご紹介します。

基本方針

EC2などのインスタンス構成からサーバーレス構成へと移行できれば、大きな削減効果が期待できるとは思いますが、アーキテクチャ変更を伴うコスト最適化は時間も手間も必要となります。

今回は「今すぐ」「簡単に」「リスクは少なく」実施できることを中心としたコスト最適化方法を扱います。

内容はシンプルなだけに既にすべての手を尽くしているユーザーも居られるかとは思いますが、今回の記事は「AWSを使い始めたばかり」「まだ削減できるムダが残っている」そういった環境を対象とした内容であることご容赦ください。

ステップ1: AWS利用費の内訳を確認する

なにわともあれ、まずAWS利用費の内容を確認し、内訳を確認しましょう。AWS利用費の内訳は各サービスごとに分類されているかと思いますので、上位TOP5あたりを確認します。

もちろんTOP5以外にも削減できる部分はあるかと思いますが、AWS利用費全体の占める割合が多いサービスから攻めたほうが、小さな労力で大きな削減が期待できます。

最近はAWS Billing Dashboardのデザインも変わり、どのサービスがたくさん使っているのか、最近になって急に増えているサービスがどれか、といった内容が視覚的に判りやすくなりましたね。（以下の例だとSageMakerが2月になって急に伸びているのが一目瞭然です）

さらに各サービスの利用費内訳を確認すると、例えば「インスタンス料金」「ストレージ料金」「データ転送料金」など、そのサービスの中でも何の項目に費用が掛かっているのかが判ります。一番、費用の掛かっている部分に対して、有効なアクションを検討しましょう。

パートナーが提供する請求代行サービスなどをご利用のアカウントは、AWSコンソールの請求情報からは実際の請求額が判断できない場合があります。その場合は各社が提供する請求情報があるかと思いますのでそちらを参照してください。

ステップ2: 止めれるものは止める

インスタンスの停止・再開

利用費の上位がEC2やRDSなど停止・再開が可能なサービスで、起動料金が費用の大半を占めている場合、まずは夜間や休日での停止が可能であるか検討しましょう。

仮に「平日夜間は8時間停止」「土日は終日停止」が可能であれば、およそ50%のコスト削減になります。

停止・再開が可能なサービスの一例は以下のとおりです。

• Amazon EC2
• Amazon RDS
• Amazon Aurora
• Amazon Redshift
• Amazon DocumentDB
• AWS Fargate（タスクまたはPod）

EC2、RDS、Auroraの停止・再開は弊社が無償で提供しているAWS運用自動化ツールの「opswitch」で簡単に実装できますので是非ともご利用ください。

Redshiftは標準機能でクラスターの停止・再開をスケジューリングできますので、こちらをご利用いただくのが良いでしょう。

DocumentDB、Fargateはopswitchや標準機能で停止・再開のスケジュール実行に対応していないので、Amazon EventBridge＋AWS Lambdaを組み合わせて実装いただく必要があります。

可用性を見直す

オンプレ構成の踏襲で「とりあえず冗長構成」として正・副のインスタンスを立てていたり、マルチAZ構成にしているものはないでしょうか？システムに求められるRPO/RTOに対して過剰な構成になってはいないでしょうか？

「RTO?RPO?そんなの決めてなかったわ、、」

ということであれば、まずはRPO/RTOを定義するとこから見直してみてはいかがでしょうか。

AuroraやDocumentDBの場合、シングル構成でもデータストアは3つのAZ、6個のレプリケーションを保持していますので高い耐久性を持っています。マルチAZ構成でなくともAZ障害時には自動復旧して再開することが可能ですので、10分程度のダウンタイムが許容できるのであればシングル構成でも十分な場合があります。

EC2もRTO/RPO次第では数時間のシステム停止で日次バックアップからの復旧でことが足りる場合があるかと思います。このようなシステムの場合、常時、可用性を持たせておくことは過剰であるとも考えられます。

使用されていないリソースの棚卸

一時的にバックアップ用途で使ったEBSが残り続けている。ながらくどこからも接続されていないRDSインスタンス。このように価値を生まないリソースにコストを払い続けてはいませんか？

AWSビジネスサポートまたはAWSエンタープライズサポートを契約されているアカウントの場合、AWS Trusted Advisorの「コストの最適化」を確認することで、先に述べたような無駄と思われるリソースの棚卸が簡単にできますので、ご確認いただくのが良いでしょう。

ステップ3: 適切なサイズに調整する

EC2:AWS Compute Optimizer

オンプレサーバーをAWSに移行する際に「とりあえず」オンプレ環境と同程度のCPU、メモリに合わせて持ってきているケースも少なくないでしょう。このような環境の場合、過剰プロビジョニングになっていないかご確認ください。

実際のワークロードよりもリッチなインスタンスサイズで稼働していることで、使い切れていないリソースに対しても費用を払い続けているのは勿体ないですね。

「AWS Compute Optimizer」は日々のワークロードを分析し、現在稼働しているインスタンスが適切なサイズであるかを判断してくれます。

仮に過剰プロビジョニングの解消により、1サイズ下のインスタンスサイズに変更することが出来ましたら、それだけでおよそ50%のコスト削減になりますのでインパクトは大きいですね。（逆にプロビジョニング不足を見つける場合もあるかもしれませんが、、）

14日間のワークロードをもとに推論する場合は無償で利用可能です。月次サイクルなど長期のワークロードも含めて算出したい場合は、分析対象の期間を3カ月に拡張することも可能です。（有償オプション）

また、インスタンスサイズだけでなくEBSについても不必要に多くのIOPSを割り当てていないか？という分析も可能です。

Nitroインスタンスへの移行

Compute Optimizerの分析結果がT2、M4などの旧世代インスタンスからT3、M6iなどのNitroインスタンスへの移行が推奨事項になっている場合があるかと思います。（旧世代より最新世代のほうがオンデマンド価格も数%安く、パフォーマンスも向上しています。）

Nitroインスタンスでの起動には「ENA拡張ネットワーキングの有効化」「NVMeドライバのインストール」が必要となりますので、旧タイプから新タイプへの切り替え時には以下の記事を参考にしてください。

RDS:Performance Insights

RDSの場合、Compute Optimizerのようなサイジングをアドバイスしてくれるツールが提供されていませんので、RDSで取得可能なメトリクスをモニタリングし、ユーザー側でリソース余りの状況であるかどうかを判断する必要があります。

モニタリングサービスとしてはAmazon CloudWatchがございますが、よりデータベースに特化した観点で洞察を得たい場合には「Performance Insights」をご利用ください。以下、AWSブログの記事がPerformance Insightsの利用方法として解りやすく説明されています。

取っ掛かりとしては「Max CPU数」のラインに対してAverage Active Sessions(AAS)が大きく下回っている状況が続いているならリソースを持てましている可能性がありますので、インスタンスサイズ縮小を検討いただく余地があるかと思います。

ステップ4: スポットインスタンスの利用を検討

• 複数台に分散されており一部のインスタンス停止が許容できる環境
• 開発・テスト用途で急なシステム停止が許容できる環境

このような環境に対してはスポットインスタンスが利用できないかを検討してみてはいかがでしょうか。

オンデマンド価格に対して最大90%の割引価格でインスタンスを利用することが可能ですので、ハマるのであればSavings Plansやリザーブドインスタンスを購入するよりも断然お得です。

2020年以降、スポットインスタンスでも停止・再開出来るようになっていますので「スポットインスタンスは終了、再作成しか出来ないからなー」という認識で見送っていた環境があれば改めて検討されてみては如何でしょうか。

またEC2だけでなくFargate、EKSなでもスポット料金が提供されています。

ステップ5: Savings Plans/リザーブドインスタンスを購入

ここまで検討して残っているリソースはきっと「最適なインスタンスサイズで常時稼働が必要なインスタンス」まで絞れていると思います。おまたせしましたSavins Plansまたはリザーブドインスタンスの購入を検討しましょう。

Savings Plans、リザーブドインスタンスに関する比較についてはチバユキさんの記事にギュギュっとまとめられていますので是非、こちらを参考にしてください。

ちなみにリザーブドインスタンスはEC2以外にも以下のサービスで購入することができます。

• Amazon RDS
• Amazon Aurora
• Amazon Redshift
• Amazon OpenSearch Service（旧Amazon Elasticsearch Service）

またリザーブド「インスタンス」ではないですがAmazon DynamoDBにもリザーブド「キャパシティ」があります。最大で70%超の割引でご利用いただけます。

100キャパシティユニット単位での購入になりますが、プロビジョニングモードで100キャパシティユニット以上お使いになられている環境であればリザーブドキャパシティをご検討いただくのも良いでしょう。

いつ買うべきか、、、。

「ずいぶん円安になったので今買うのは損になりませんか、、？」

「1年前の1ドル102円の頃にSavings Plans/リザーブドインスタンスを買っていれば、、」と思う気持ちはわかりますが、過去に戻ることはできません。

「ずいぶん円安になったので少し戻したら買おうかと思います」

では、ちょっと為替のチャートでも眺めながら購入タイミングを考えますか。

なるほど、わからん。

私が為替の未来を見通せるなら的確にアドバイスしたいところですが、そのようなスキルがあればそちらを本業にしているでしょうから、こうしてブログを書いてることもないでしょう。。

ひとつ確実にお伝えできることは「オンデマンド価格よりもSavings Plans/リザーブドインスタンスのほうが割引がある」ということだけです。

しばらく待てば1ドル116円に戻す可能性もあるでしょうが、126円が116円になったとしても変動は8%です。

仮に、東京リージョンのM5インスタンス（Linux）をEC2 Instance Savings Plansで1年・全額前払いで購入した場合、41%の割引が得られます。執筆時点では1ドル126円ですので、41%OFFを為替に換算すると1ドル74円です。史上最高値の1ドル75円を上回りましたね！

個人的な見解ですが、いつ来るか来ないかわからない数パーセントの為替の戻りを待つよりも、確実に手に入る数十パーセントの割引を得た方が良いのではないでしょうか。

その他

今回は主にインスタンス系のサービスによるコスト最適化の内容に偏っていますが、EC2やRDS以外の部分で無駄が気になる方は以下、深澤の「え、そんなに！？意外と知らないAWSでお金がかかるポイント5選！！」シリーズの記事を参照いただくと何か気付きが得られるかもしれません。

また弊社が提供する「クラスメソッドメンバーズ」もAWSを安く利用できるサービスとなっていますので、あわせてご検討いただけると幸いです！(宣伝です)

まとめ

• 為替が円安に振れていることで国内ユーザーの多くはAWS利用費のコストが増えている
  • USドルの請求額は1年前と同じでも、日本円での負担は20%増加している
• 「為替変動怖い、クラウド怖い」ではなく、クラウドだからこそ環境見直して柔軟に対応することでコストを調整できる
• コスト最適化の5ステップ
  • ステップ1: AWS利用費の内訳を確認する
  • ステップ2: 止めれるものは止める
  • ステップ3: 適切なサイズに調整する
  • ステップ4: スポットインスタンスの利用を検討
  • ステップ5: Savings Plans/リザーブドインスタンスを購入